Data storage systems, such as disk drives, disk storage arrays, network storage devices, storage area networks, and the like, are called upon to store and manage a significant amount of data (e.g., gigabytes, terabytes, petabytes, etc.) that is written and read by many users. For example, a traditional storage array may include a collection of hard disk drives operating together logically as a unified storage device. Storage arrays are typically used to provide storage space for a plurality of computer file systems, databases, applications, and the like. For this and other reasons, it is common for physical storage arrays to be logically partitioned into chunks of storage space, called logical units, or LUs. This allows a unified storage array to appear as a collection of separate file systems, network drives, and/or volumes.
Presently, there is a trend toward the use of larger operating systems, larger applications or programs, and larger file sizes. Understanding this trend, a storage administrator is likely to request the provisioning (i.e., allocation) of a larger portion of storage space than is currently required for an operating system, for example, with the expectation that the space requirements will grow with upgrades, bug-fixes, the inclusion of additional features, and the like.
However, a problem of underuse typically arises when the amount of storage space is fully provisioned and allocated to, but is not used by, an operating system, program, process, or user. In this scenario, the disk storage space is unused by the entity that requested its allocation and is also rendered unavailable for use by any other entity. In such cases, the unused space cannot be simply given back to a common storage pool where it may become accessible to other users. For example, a database installation may require many terabytes of storage over the long term even though only a small fraction of that space may be needed when the database is first placed into operation. In short, the large storage space may eventually be needed, but it is not known exactly when the entire space will be required. In the meantime, the allocated storage space lies unused by the requested user and may not be utilized by any other user.
In recognition of the fact that more storage space may be provisioned for operating systems, programs, and users than can actually be used at first, the concept of a sparsely populated logical unit (LU), such as a “thin” logical unit (TLU), was developed. Unlike the more traditional fully allocated logical unit, which is created by fully provisioning and an entire initial amount of storage area, a sparsely populated logical unit is provisioned at creation but is not allocated any physical storage until the storage is actually needed. Specifically, a TLU resolves this problem by allocating the storage space (e.g., making the memory space physically available) as it is needed when (or shortly before) data is written to the TLU. A TLU is created from a common pool of physical space and starts with minimal amount of physical space. As the application that is using the TLU starts to demand more storage, the TLU incrementally requests the storage space from the common storage pool in portions referred to as slices.
Although the TLU enables a user to avoid allocating unnecessary storage space from a common storage pool, there are still some instances where a TLU may comprise allocated areas of storage space (i.e., allocated slices) that are not being used. Notably, the TLU may be subjected to certain data storage optimization operations, such as a logical unit number (LUN) shrink, a LUN compression, or a LUN zeroing operation. In general, these operations can free up storage space in the TLU, thereby creating unused allocated slices. In many cases, this unused storage space cannot simply be given back to the common storage pool and allocated to other users. Thus, the use of these data storage optimization operations can result in the inefficient use of storage space within the TLU. Such a problem remains until the unused allocated slices in the TLU are eventually utilized (e.g., written to).
Accordingly, there exists a need for systems, methods, and computer readable media for triggering and coordinating pool storage reclamation.